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SUMMARY 


This  is  a  consolidation  of  the  preliminary  work  done  in  the  application 
of  a  General  Reliability  Analysis  Simulation  Program  (GRASP)  for  the  Lockheed 
Remotely  Piloted  Vehicle  (RPV)  system,  being  developed  for  the  United  States 
Army. 

v 

The  model  simulates  the  field  operation  of  the  RPV  system.  By  using 
individual  component  reliabilities,  the  overall  reliability  of  the  RPV  system 
is  determined.  The  results  of  the  simulations  are  given  in  operational  days. 
The  model  represented  is  only  a  basis  from  which  more  detailed  work  could 
progress. 

ifce  RPV  system  in  this  model  is  based  on  preliminary  specifications  and 
estimated  values.  The  scope  of  this  report  demonstrates  the  use  of  GRASP  from 
basic  system  definition,  to  model  input*  and  to  model  verification. 

K 

INTRODUCTION 


This  report  is  a  consolidation  of  the  preliminary  work  done  in  the  appli¬ 
cation  of  a  General  Reliability  Analysis  Simulation  Program  (GRASP)  for  the 
Lockheed  Remotely  Piloted  Vehicle  (RPV)  system,  being  developed  for  the  United 
States  Army. 

This  paper  demonstrates  the  process  used  to  create  the  RPV  model,  to 
change  the  model  into  the  RPV  data  set,  to  validate  the  RPV  model/data  set, 
and  the  steps  necessary  to  interpret  the  output.  The  results  of  the  GRASP 
simulation  are  expressed  in  successful  operational  days.  A  successful  opera¬ 
tional  day  is  defined  as  the  completion  of  three  3-hr  mission  flights  in  a 
12-hr  period.  Each  simulation  begins  with  five  new  air  vehicles  and  all 
ground  equipment  in  operational  status. 

The  conclusion  of  the  report  emphasizes  the  versatility  of  using  GRASP, 
and  the  status  of  the  RPV  data  sets. 


ABBREVAITIONS 


ADT  air  data  terminal  (part  of  MICNS  communications  package) 

AF  air  frame 

ARA  air  reference  assembly 

AV  air  vehicle 

AVIM  air  vehicle  intermediate  maintenance 

AVO  air  vehicle  operator 

AVOC  air  vehicle  operator  console 

AVUM  air  vehicle  unit  maintenance 

EPS  electrical  power  system 

FCEP  flight  control  electronics  package 

FLT  flight 

GCS  ground  control  station 

GCSIU  GCS  interfacing  unit 

GEN  generator 

GRASP  generalized  reliability  analysis  simulation  program 
GSE  ground  support  equipment 

IR  infrared  (landing  system) 

LA  launcher  assembly 

LMSC  Lockheed  Missiles  and  Space  Company 

LRU  line-replaceable  units 

MAIM  main  GCS  computer 

MC  mission  commander 

MCO  mission  commander  operator 

MCOC  mission  commander  operator  console 

MICNS  modular  integrated  control  navigation  Bystem 

MP  mission  payload 

MPC  mission  payload  operator  console 

MPO  mission  payload  operator 

MPS  mission  payload  subsystem 

MS  maintenance  shelter 

MTBF  mean  time  before  failure 

NAV  navigation 

NPV  navigation  display  unit 

PROP  propulsion  assembly 

REC  recovery  subsystem 

RGT  remote  ground  terminal 

RPV  remotely  piloted  vehicle 

TTF  time  to  fail 

TTR  time  to  repair 

GRASP  II  COMPUTER  PROGRAM  REVIEW 

GRASP  II  (Version  II)  is  a  Fortran-based  computer  program  which  can  simu¬ 
late  a  reliability-based  system  operation  consisting  of  time  and  cost.  GRASP 
is  a  method  by  which  a  system  can  be  represented  by  certain  parameters  and 
logical  relationships,  and  be  shown  graphically  as  a  network  diagram  present¬ 
ing  the  reliability  configuration  of  that  system. 
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In  order  for  a  model  to  be  developed,  certain  building  blocks  must  be 
understood.  GRASP  network  diagramming  is  based  on  two  basic  elements:  nodes 
and  arcs.  Nodes  are  events  in  the  system,  such  as  a  failure  of  a  component, 
end  of  a  repair,  or  completion  of  any  other  type  of  activity.  Nodes  are 
denoted  by  circles  in  which  N1  is  the  number  of  pulses  needed  to  release  the 
node  the  first  time  and  N2  is  the  number  of  pulses  needed  to  release  the 
node  at  subsequent  times.  Arcs,  or  branches,  represent  time-consuming  activ¬ 
ities,  such  as  time-to-fail  (TTF) ,  time-to-repair  (HR),  or  any  event  prece¬ 
dence  relationship  in  the  system.  Event  precedence  relationships  have  no 
duration,  that  is,  they  occur  instantaneously.  (See  figure  1  for  examples  of 
nodes  and  arcs.) 

This  is  a  basic  look  at  the  GRASP  network  diagram.  Further  information 
can  be  obtained  from  the  GRASP  Users  Manual,  and  it  is  recommended  that  the 
reader  review  and  become  familiar  with  GRASP  if  a  more  detailed  discussion  is 
required. 


NODE 


ARC 


Figure  1.-  Arc  and  node  diagram. 


COMPOSITION  OF  THE  LOCKHEED  RPV  SYSTEM 


The  Lockheed  RPV  system  consists  of  several  components.  These  components 
divide  the  RPV  system  into  key  factors  from  which  a  network  model  can  be  made. 
In  the  following  discussion,  the  overall  mission  function  is  first  explained 
and  then  the  individual  components  are  described  as  they  relate  to  the  system. 
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The  RPV  system,  as  addressed  in  this  report,  is  a  combination  of  hardware 
and  mission  function.  The  hardware  consists  of  mobile  ground  units  used  to 
support  the  air  vehicles  (AV)  and  the  five  AV's  used  for  mission  function. 

The  mission  function  consists  of  spotting  and  designating  targets.  The 
steps  in  this  process  include  the  prelaunch  check  (making  sure  all  systems  are 
working);  the  climb-out;  the  outbound  flight;  the  mission  stage  where  targets 
are  found  and  identified;  the  Inbound  flight,  which  is  similar  to  the  outbound 
flight;  and  the  recovery  of  the  AV.  The  mission  occurs  between  the  outbound 
and  inbound  flight  segments. 

The  hardware  consists  of  seven  mobile  ground  units: 

1.  Launcher  truck 

2.  GCS  (Ground  Control  Station) 

3.  Recovery  truck 

4.  MS  (Maintenance  Shelter) 

5.  Crane  truck  (truck  carries  two  AV's) 

6.  AV  truck  (truck  carries  three  AV's) 

7.  Pickup  truck 

Trailers  for  transporting  the  Remote  Ground  Terminal  (RGT)  and  two  generators 
are  also  required. 

The  GCS  controls  the  AV  while  the  AV  is  in  flight.  It  can  also  perform 
the  checkout  during  prelaunch  and  monitor  tests  during  a  mission  flight.  The 
MS  (Maintenance  Shelter)  is  a  field  workshop  for  repairing  the  AV's,  GCS,  RGT, 
generators,  launcher,  and  recovery  truck. 

The  following  description  of  the  RPV  system  provides  a  working  knowledge 
of  the  basic  system  characteristics  as  they  relate  to  this  report;  it  is 
public  information,  having  been  published  in  Aviation  Week  and  Space  Technol¬ 
ogy  (vol.  112,  no.  2,  Jan.  7,  1980,  pp.  54-63). 

The  major  areas  of  reliability  concern  are  between  stages  C  to  F  (fig.  2), 
where  C  to  D  to  E  is  system  checkout,  E  to  F  is  AV  flight  and  mission  opera¬ 
tions,  and  F  to  "or"  is  the  recovery  of  the  AV.  Although  factors  of  emplace¬ 
ment  leading  up  to  state  C  can  be  modeled,  a  limit  must  be  placed  on  the  size 
of  the  RPV  system  being  modeled  by  GRASP;  therefore,  the  system  of  emplacement 
has  been  disregarded. 

An  objective  of  the  model  analysis  is  to  simulate  the  operational  limits 
of  a  fielded  RPV  unit,  that  is,  how  many  days  can  the  system  operate  (success¬ 
fully)  from  a  fresh  start,  where  a  successful  day  is  defined  as  three  success¬ 
ful  mission  flights  being  performed  within  a  12-hr  period.  Thus  the  RPV 
system  baseline  model  revolves  around  prelaunch  and  flight  of  the  AV's. 

The  day  begins  with  an  AV  on  the  launcher  ready  for  its  prelaunch  check. 

If  it  is  determined  that  the  AV  fails  the  prelaunch  check,  the  prelaunch  is 
aborted.  The  model  will  start  a  removal  (time  15  min)  of  the  bad  AV  from  the 
launcher  and  replace  it  (in  15  min)  with  a  good  AV  from  the  ready-pool.  If 
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Functional  baseline 


the  GCS  or  any  other  ground  equipment  falls  and  causes  the  launch  to  be 
aborted,  the  model  aborts  and  waits  until  the  failed  component  is  fixed.  Upon 
repair  the  model  begins  a  new  prelaunch  check. 

The  GRASP  model  cannot  detect  multiple  failures  at  a  single  time.  For 
example,  if  the  GCS  and  a  generator  fall  at  the  same  time,  the  GRASP  selects 
the  one  that  was  coded  in  first  into  the  program  and  selects  that  particular 
one  as  the  failed  component.  In  any  case,  this  is  not  a  problem  because  the 
failure  rates  are  low  to  start  with. 

Using  the  above  example,  another  assumption,  based  on  low  failure  rates, 
is  that  if  the  GCS  and  generator  fail  at  the  same  time,  they  go  into  repair 
at  the  same  time.  The  modeled  RPV  system  has  only  one  Maintenance  Shelter 
(MS)  and  multiple  repairs  are  handled  on  a  sequential  priority  basis. 

The  key  functional  paths  used  in  the  model  are  diagrammed  in  figure  3, 
which  shows  how  the  AV’s  are  used  in  the  system. 


Figure  3.-  Functional  paths. 


After  being  provided  with  some  initial  assumptions,  a  meeting  was  held 
wherein  more  refined  assumptions  were  Incorporated  into  the  model.  Those 
assumptions  are  listed  below: 

1.  If  GCS  main  computer  fails  during  a  mission,  the  mission  is  aborted 
and  inbound  and  recovery  paths  are  set  up.  Note  that  the  recovery 
operates  at  lower  values. 

2.  The  laser  is  needed  for  the  mission  and  is  only  used  during  the  out' 
bound  flight  for  position  updating. 


3.  The  recovery  stage  of  the  mission  flight  can  be  successful  with  IR 
or  MPS  recovery  systems.  Note  that  only  '-tPS  is  used  when  IR  is  down. 

4.  If  a  subsystem  goes  down,  it  goes  into  repair  without  delay. 

(Example:  A V,  GCS,  RGT,  GSE,  LA,  Recovery.)  The  probability  of  more 

than  one  subsystem  being  down  at  the  same  time  is  low. 

5.  Launcher  and  Recovery  hardware  will  only  fail  in  an  active  state. 

6.  GSE  refers  explicitly  to  power  generators.  Note  that  the  remote 
ground  terminal  has  its  own  generators. 

7.  Of  the  three  different  maintenance  systems,  each  exhibits  its  own 
characteristics  for  isolation  of  problems. 

A  chart  was  made  up  showing  the  reactions  of  the  possible  failed  com¬ 
ponents  during  possible  events.  This  provided  a  framework  upon  which  the 

complete  RPV  system  was  composed  into  functional  elements.  A  GRASP  network 

diagram  is  constructed  from  table  1.  This  topic  will  be  discussed  in  the 
next  section. 


BUILDING  OF  THE  GRASP  NETWORK 


In  the  previous  section  the  RPV  system  was  broken  down  into  functional 
elements.  The  idea  was  to  represent  these  functional  elements  as  nodes 
(events)  and  arcs  (timed  activities).  The  key  hardware  elements  are  the  AV, 
GCS,  RGT  trailer,  generators,  launcher  assembly  truck,  and  recovery  truck. 

For  the  reliability  model  and  GRASP  network  model,  the  AV  will  be  repre¬ 
sented  by  seven  subsystems. 

1.  MP:  mission  payload 

2.  FCEP:  flight  control  electronic  package  and  flight  sensor  package 

3.  ARA:  air  reference  assembly 

4.  ADT:  air  data  terminal 

5.  EPS:  electrical  power  system 

6.  AF:  airframe 

7.  PROP:  propulsion  assembly 

Certain  assumptions  that  pertain  to  the  AV  are  described  next.  It  was 
assumed  that  failure  during  prelaunch  of  any  of  the  AV  subsystems  (1  through  7) 
would  cause  the  launch  to  be  aborted.  This  is  then  followed  by  removal  of  the 
failed  AV  (15  min)  and  its  replacement  on  the  launcher  with  a  good  AV  from  the 
ready-pool. 

The  AV  subsystems  were  also  modeled  allowing  for  failure  of  the  MP 
(mission  payload)  package  during  flight.  This  failure  would  result  in  the 
return  of  the  AV  with  the  proper  sequencing  time.  Also,  upon  recovery  of  the 
AV  with  the  failed  MP,  a  reduced  reliability  of  recovery  occurs.  Sequencing 
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TABLE  1.-  FAILURE  MODES  FOR  SUBSYSTEMS 


Action 

Failure 

Launch 

Prelaunch 

climb-out 

Outbound 

Mission 

Inbound 

Resources 

Two  of  three 
consoles3 

Repair 

recycle 

AV  lost 

AV  lost 

AV  lost 

AV 

lost 

AV  lost 

One  of  three 
consoles3 

Repair 

recycle 

Recovery 

Inbound/ 

recovery 

Inbound/ 

recovery 

Recovery 

No  effect 

Navigation 

display 

unit3 

Repair 

recycle 

Recovery 

Inbound/ 

recovery 

Inbound / 
recovery 

No 

effect 

No  effect 

Main 

computer3 

Repair 

recycle 

Recovery 

Inbound/ 

recovery 

Inbound/ 

recovery 

No 

effect 

Recovery 

degraded 

mode 

GCS  I/Ua 

Repair 

recycle 

AV  lost 

AV  lost 

AV  lost 

AV 

lost 

AV  lost 

Launcher 

hardware 

Repair 

recycle 

No  effect 

No  effect 

No  effect 

No 

effect 

No  effect 

Recovery 

hardware 

No  effect 

No  effect 

No  effect 

No  effect 

No 

effect 

AV  lost 

GSE 

Repair 

recycle 

AV  lost 

AV  lost 

AV  lost 

AV 

lost 

AV  lost 

RGT3 

Repair 

recycle 

AV  lost 

AV  lost 

AV  lost 

AV 

lost 

AV  lost 

MPS/TV 

Repair 

recycle 

Recovery 

Inbound/ 

recovery 

Inbound/ 

recovery 

No 

effect 

IR  only 

Laser 

Repair 

recycle 

Recovery 

Inbound/ 

recovery 

Inbound/ 

recovery 

No 

effect 

No  effect 

FCEP 

Repair 

recycle 

AV  lost 

AV  lost 

AV  lost 

AV 

lost 

AV  lost 

ARA 

Repair 

recycle 

AV  lost 

AV  lost 

AV  lost 

AV 

lost 

AV  lost 

Propulsion 

Repair 

recycle 

AV  lost 

AV  lost 

AV  lost 

AV 

lost 

AV  lost 

ADT 

Repair 

recycle 

AV  lost 

AV  lost 

AV  lost 

AV 

lost 

AV  lost 

IR 

Repair 

recycle 

No  effect 

No  effect 

No  effect 

No 

effect 

MPS 

landing 

A 

10-min  delay  to  determine  if  equipment  cannot  be  placed  back  into  operational 
status. 
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time  refers  to  the  time  needed  for  the  return  of  an  AV  in  the  event  of  a  fail¬ 
ure.  If  the  AV  is  on  climb-out  or  outbound  and  a  failure  occurs,  then  the  AV 
is  returned.  The  time  that  the  model  has  used  to  get  the  AV  to  the  climb-out 
or  outbound  is  assumed  small.  If  the  MP  fail'  on  the  mission  phase,  then  the 
model  starts  an  inbound  flight  upon  detection  of  the  failure.  Thus  the  25-min 
period  for  the  inbound  flight  is  not  negligible  as  was  the  case  in  the  failure 
of  the  MP  during  climb-out  or  outbound  flight. 

The  modeling  of  the  other  hardware  elements  is  not  as  complicated  as  that 
of  the  MP.  The  AV  subsystems  are  grouped  together.  As  stated  before,  if  any 
of  these  subsystems  fail  during  the  prelaunch,  the  launch  is  then  aborted  and 
AV  replacement  procedures  are  started.  If  the  other  items  fail  during  flight 
(excluding  MP)  then  the  model  will  crash  the  AV  at  the  time  of  failure  and 
begin  the  launch  of  a  new  AV. 

Upon  successful  launch  of  the  AV,  another  AV  from  the  AV  ready-pool  is 
placed  on  the  launcher.  This  process  is  done  so  that  if  the  AV  in  the  air 
fails  and  crashes,  then  the  AV  on  the  launcher  is  ready  for  its  prelaunch 
checkout . 

During  the  mission  flight  the  AV  is-  continually  checked  as  two  separate 
systems:  (1)  the  mission  payload,  and  (2)  items  2  through  7  above  (p.  7). 

If  any  of  these  systems  fail,  the  model  will  properly  select  the  path  for  that 
failure  to  be  recognized. 

The  GCS  has  10  major  subsystems  for  its  model.  Of  these  10,  only  6  are 
necessary  for  proper  modeling:  the  three  consoles,  the  GCS  Interface  Unit 
(IU) ,  the  navigation  display,  and  the  main  computer. 

The  omission  of  the  communications  equipment  is  justified  because  there 
is  adequate  redundancy  in  that  system  and  because  the  communications  network 
does  not  directly  affect  the  critical  operation  of  either  the  RPV  or  AV. 

The  AVO  (air  vehicle  operator)  console,  MPO  (mission  payload  operator) 
console,  and  the  MCO  (mission  commander  operator)  console  are  assumed  to 
operate  in  a  somewhat  redundant  fashion.  That  is,  *f  one  console  fails  then 
the  AV  can  still  be  controlled  (to  a  limited  extent)  and  return  of  the  AV  is 
initiated.  If  two  consoles  fall,  control  of  the  AV  cannot  be  maintained  and 
the  AV  is  lost.  There  is  a  10-min  timer  that  sets  the  limits  for  repair  of 
the  GCS  and  reestablishment  of  communications  with  the  AV.  These  10-min 
timers  are  not  only  for  the  consoles  but  also  for  other  GCS  subsystems  in  the 
model. 

Of  the  six  components  used  to  model  the  GCS  there  are  only  two  failures 
that  result  in  loss  of  the  AV:  a  two-console  failure  (as  stated  before)  and 
loss  of  the  GCS  interface  unit  computer. 

If  a  model  component  fails  and  is  not  sent  immediately  to  repair,  a 
repair  facility  is  designated  for  that  component.  (Note  that  this  is  based 
on  low  failure  rates.)  For  the  GCS  model,  GRASP  generates  only  one  set  of 
failure  data  at  the  start  of  the  simulation.  When  a  GCS  subsystem  fails, 


GRASP  generates  a  new  mean  time  between  failure  (MTBF)  for  that  particular 
subsystem  only,  unlike  the  AV  model  in  which  a  new  set  is  derived  for  each 
flight  at  prelaunch. 

If  the  GCS  does  go  down  and  an  AV  is  lost,  the  model  waits  until  the  GCS 
is  back  up  (arc  141-142  value  #31)  before  starting  a  prelaunch  check  (node  6 
to  start  prelaunch  at  node  2) .  Node  6  monitors  the  status  of  the  GCS  from 
node  152.  When  node  6  releases  then  it  is  known  that  an  AV  is  on  the  launcher 
and  that  the  GCS  is  ready  to  do  a  prelaunch. 


VERIFICATION  PROCESS 


As  with  any  program,  experience  in  debugging  is  an  essential  element  when 
input  errors  or  logic  errors  surface.  Both  errors  are  difficult  to  correct, 
but  finding  the  logic  errors  seems  to  be  more  challenging.  GRASP  has  an 
option  that  is  very  useful  in  finding  these  logic  errors.  It  is  called  the 
trace  option,  as  specified  on  the  first  input  card.  The  trace  option  gives 
the  user  a  printout  of  the  step-by-step  pulse  actions  that  occur  in  the  model. 

After  the  model  has  been  diagrammed,  it  must  then  be  incoded  in  the 
proper  order  for  input  into  the  GRASP  program.  The  best  process  for  checking 
the  input  is  a  node-by-node,  arc-by-arc  review.  This  process  is  most  effec¬ 
tively  done  by  two  persons:  one  to  read  the  node  from  the  network  diagram 
and  the  other  to  check  it  off  on  the  computer  printout.  This  process  checks 
for  input  errors  that  may  have  occurred. 

Next,  the  trace  option  is  employed  to  analyze  the  output  and  validate 
the  pathway  of  the  pulse.  In  validating  the  model,  errors  surface  easily  and 
can  be  identified  quickly.  In  one  example,  the  trace  option  located  a  mis¬ 
placed  arc,  which  was  causing  a  pulse  to  split  in  two.  After  locating  the 
problem,  it  was  soon  corrected.  The  trace  option,  furthermore,  follows  the 
logic  pattern  of  the  model,  thus  providing  an  easy  way  to  check  for  logic 
errors . 


SAMPLE  INTERPRETATION 


A  total  of  14  different  model-system  configurations  were  addressed,  each 
evaluated  on  a  nodal-observation  basis.  The  frequency  of  a  node's  occurrence 
was  recorded  on  a  cumulative  basis.  Ocher  information  was  provided  such  as 
minimum  time  of  occurrence,  maximum  time  of  occurrence,  and  standard  devia¬ 
tion.  For  our  particular  model,  only  the  number  of  observations  was  important. 
Other  features  could  be  incorporated,  but  because  of  the  simplistic  nature  of 
the  model  they  were  omitted.  Thus  the  number  of  observations  could  be  con¬ 
verted  into  the  number  of  days  the  RPV  system  is  operational.  A  sample  run 
follows,  which  serves  to  demonstrate  the  method  of  interpretation. 
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Node 

Number  of  observations 

5 

27 

182 

23 

299 

50 

Number  of  observations  (node  5)  =  27 

Number  of  simulations  ■  100 

27/100  =  27% 


Nodes  5  and  182  show  a  system-failure  situation,  with  the  nodes  indicating  the 
cause  or  source  of  failure.  Node  5  was  observed  27  times  in  100  simulations, 
indicating  a  27-percent  occurrence  due  to  depletion  of  available  air  vehicles. 
Node  182  was  observed  23  times,  indicating  a  23-percent  occurrence  due  to 
incomplete  3-hr  missions  in  the  12-hr  periods.  Node  299  (indicating  success¬ 
ful  missions)  was  observed  50  times  in  100  simulations,  showing  10  successful 
operational  days  without  failure  of  the  RPV  system. 


RECOMMENDATIONS 


The  system  model  discussed  in  this  paper  is  only  a  base  from  which  more 
detailed  work  could  progress.  Significant  improvements  might  include: 

1.  Adding  cost  to  the  model.  Although  not  specified  in  this  report, 
additional  cost  requirements  and  values  could  be  assigned  after  preliminary 
research. 


2.  Varying  the  mission  time.  This  model  uses  a  maximum  time  of  3  hr 
(plus  5  min  prelaunch)  to  perform  a  mission  scenario.  A  routine  could  be 
designed  to  vary  the  mission  time  between  1  hr  and  3  hr. 

3.  Modeling  the  subsystems  past  the  line-replaceable  units  (LRU's)  to 
the  board  level  or  part  level.  This  would  provide  far  greater  accuracy  in 
the  function  and  operation  of  the  system. 

4.  Finding  the  average  number  of  operational  days.  This  model  now 
determines  the  number  of  operational  days  until  three  successful  flights  cannot 
be  completed  within  12  hr.  The  model  could  be  altered  to  determine,  for 
example,  that  in  100  days,  80  are  operational  (i.e.,  producing  successful 
missions)  and  20  are  failures. 

At  the  conclusion  of  this  project,  additional  features  were  requested 
from  Lockheed,  but  there  was  no  time  to  implement  them.  However,  Lockheed 
suggested  changing  the  failure  rate  for  the  AV  subsystem  so  that  a  percentage 
of  the  failures  would  cause  the  AV  to  crash.  Figure  4  shows  the  present 
failure  monitor  features  of  the  AV  subsystem,  and  figure  5  shows  the  effects 
of  changing  the  features  to  accommodate  a  percentage  of  failures. 
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The  RPV  system  In  this  model  is  based  on  specifications  and  estimated 
values,  and  the  reader  should  bear  in  mind  that  corrections  of  data  values  or 
modifications  may  be  necessary  as  time  goes  on.  It  should  also  be  noted  that 
the  status  of  the  model  presented  in  this  report  is  by  no  means  indicative  of 
the  operational  status  of  the  RPV  system  under  development  at  LMSC. 


Figure  4.-  Current  AV  subsystem. 
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Figure  6.-  Prelaunch,  cliabout 


Figure  8.-  Inbound,  recovery 


BACK  IN  POOL 


Figure  9.-  Recovery,  timer 


GROUND  EQUIPMENT 


subsystem,  ground  equipment 


GCS  SUBSYSTEM 


GCS  subsystem,  ground  equipment. 


APPENDIX  B 
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NODE-ARC  DESCRIPTIONS 
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This  section  describes  the  meanings  for  the  nodes  and  arcs  in  the  node 
diagrams.  The  section  is  categorized  by  node  number  with  the  description  of 
the  arcs  following. 


PRELAUNCH,  CLIMBOUT  (Figure  6) 

Node  _ Significance _ 

2  Indicates  stare  of  simulation,  start  of  pref light /prelaunch  check 

Arc  2-11:  begins  prelaunch  check 

Arc  2-81:  checks  the  AV  for  starting  new  distribution 

3  Indicates  abort  required  due  to  AV  failure 

Arc  3-10:  issues  abort 

Arc  3-5:  removes  inoperative  AV  from  launcher  within  a 

15-min  period 

Distribution  1 ,  parameter  8 

4  Indicates  new  AV  from  pool  placed  on  launcher 

Arc  4-6:  requires  15-min  replacement  period 

Distribution  1,  parameter  8 

Arc  4-5:  removes  one  AV  from  ready-pool 

5  Indicates  number  of  AV's  used:  N1  =  5,  N2  =  5  (N2  indicates 
all  AV's  used;  simulation  over) 

6  Indicates  simultaneous  readiness  of  GCS  and  of  AV  on  launcher 

Arc  6-2:  both  GCS  and  AV  ready  for  prelaunch  check 

7  Indicates  prelaunch  check  stopped  due  to  ground  component 
failure  (GEN  &  RGT);  15  performed  but  not  14 

Arc  7-178:  ground  equipment  working 

8  Indicates  ground  equipment  not  working;  waiting  for  repair 
(14)  from  arc  93-94 

Arc  8-8:  pulse  cycling  on  1-min 

Distribution  1,  parameter  1;  wait  for  repair 

178  Indicates  whether  prelaunch  was  aborted  due  to  GCS  failure 

Arc  178-9:  GCS  backup 

179  Indicates  GCS  still  down  in  repair 

Arc  179-179:  1-min  check  —  when  GCS  repaired,  pulse  transfers 
back  to  arc  178-9 
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Node 


Significance 


9  Indicates  junction  (receiver  node);  ready  to  begin  prelaunch 
Arc  9-10:  updater  arc  to  count  aborts 
Arc  9-2:  repairs  finished,  start  prelaunch  again 

10  Indicates  number  of  aborts  during  prelaunch  due  to  AV,  GCS,  or 
GND  (nodes  12,  14,  26  respectively);  aborts  due  to  no-engine 
start  (node  19);  and  during  a  failed  launcher  (node  21) 

11  Indicates  prelaunch  check  of  AV  systems;  if  AV  not  working  a 
10  from  103-9  occurs,  thus  replacing  11  by  12 

12  Indicates  AV  not  working,  10  occurred  in  AV  subsystem  103-9 
Arc  12-15:  update  1-min  back  counter  (-2) 

Arc  12-17:  update  5-min  front  counter  (-5) 

Arc  12-6:  shows  GCS  still  functioning 

Arc  12-3:  starts  removal  and  replacement  of  AV 

13  Indicates  whether  ground  equipment  (GENs  and  RGT)  is  working  — 
if  not,  15  occurs  from  arc  95-96,  output  of  node  13  is 
replaced  by  node  14 

Arc  13-16:  ground  equipment  working,  continue  prelaunch  check 

14  Indicates  ground  equipment  failure  (caused  by  15  from  arc  95-96) , 
stops  prelaunch  for  repairs 

Arc  14-17:  update  5-min  front  counter  (-5) 

Arc  14-15:  update  1-min  back  counter  (-2) 

Arc  14-7:  removal  pulse  to  node  7,  where  node  7/8  releases 

pulse  when  ground  equipment  is  repaired 

16  Indicates  whether  GCS  is  working  —  if  not,  30  from  arc  143-144 
replaces  output  of  16  with  output  of  26 
Arc  16-17:  indicates  GCS  working,  updates  node  17  and 
decreases  5  to  4,  then  4  to  3,  etc.  (This 
is  how  5  min  are  counted.  If  prelaunch  time 
is  changed  to  10  min,  then  replace  N1  and  N2  of 
node  17  with  10) 

Arc  16-15:  1-min  loop  back  occurring  5  times  results  in 
5  min  for  prelaunch  node  15  at  1  (due  to  11); 
at  0,  node  releases  and  prelaunch  starts  again 

26  Indicates  GCS  failure  (caused  by  30  from  arc  143-144);  pre¬ 
launch  stopped  for  repairs  which  puts  node  26  with  16 
Arc  26-17:  update  5-min  front  counter  (-5) 

Arc  26-15:  update  1-min  back  counter  (-2) 

Arc  26-7:  GCS  failure,  waits  at  7  until  GCS  repaired 

(actually,  7  moves  to  178,  but  model  waits 
at  179,  continues  check  until  GCS  is  ready) 
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Node 


Significance 


15  Indicates  reset  of  1-min  counter  if  prelaunch  aborted  by  12, 

14,  26,  or  17  (when  released) 

Arc  15-11:  start  prelaunch  again 

17  Indicates  the  number  of  1-min  checks  that  have  been  made  (if 
prelaunch  becomes  10  min,  change  N1  and  N2  to  10) 

Arc  17-18:  prelaunch  acceptable,  attempt  to  start  engine 
Arc  17-15:  update  1-min  counter  to  stop 

Indicates  another  prelaunch  check  —  if  another  item  needs  to  be 
checked  during  prelaunch,  follow  same  format;  arc  13-16  includes 
possibility  for  failure  as  represented  by  dotted  lines,  and  must 
have  repair  status  like  GCS  [3l]  .  Also, 

1)  Update  17  with  -5 

2)  Update  15  with  -2 

3)  Divert  to  7  to  create  failure  similar  to  GCS 

4)  Place  operating  up  and  down  between  Arc  7-178 

18  Indicates  engine  start,  a  probablistic  node  in  that  the  engine 
may  or  may  not  work 

Arc  18-20:  the  probability  of  the  engine  working  .999  defined  on  arc 

Arc  18-19:  the  probability  of  the  engine  not  working  .001  defined 

on  arc 

19  Indicates  engine  did  not  start,  AV  failed  on  launcher 

Arc  19-3:  start  abort  and  replacement  of  AV 

20  Indicates  engine  working,  the  command  is  given  for  the  launch  of  AV 
Arc  20-21:  launcher  failed  .001,  needs  15-min  to  repair 

Arc  20-22:  launcher  worked,  AV  in  air,  .999,  mission  flight  has  begun 

21  Indicates  launcher  failed  but  has  been  fixed  now  due  to  the  15  min 
along  arc  20-21 

Arc  21-9:  count  as  abort  so  that  another  prelaunch  can  begin 

22  Indicates  launcher  worked,  AV  in  air  and  mission  flight  has  begun 

Arc  22-4:  start  the  15  min  needed  to  prepare  another  AV  on  the 

launcher 

Arc  22-23:  1-min  time  no  signal,  just  sending  pulse  to  climbout 

23  Indicates  AV  is  up  and  working  (similar  to  prelaunch  node  11) 

Arc  23-24:  AV  has  failed  somewhere 

Arc  23-25:  Update  arc  for  the  5-min  climbout 

Arc  23-27:  AV  OK,  continue  to  check  other  components 
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Significance 


Indicates  AV  failure,  AV  will  crash  or  an  MP  failed  and  will  be 
taken  up  in  154 

Arc  24-29:  update  5-min  counter  (-5) 

Arc  24-25:  update  1-min  counter  (-2) 

Arc  24-71:  failure  of  mission  flight 

(see  36) 

Arc  25-23 

Indicates  ground  equipment  system  check 
Arc  27-28:  failure 

Arc  27-37:  ground  equipment  OK,  continue 

Indicates  ground  equipment  failure 
Arc  28-29:  update  5-min  counter  (-5) 

Arc  28-25:  update  1-min  counter  (-2) 

Arc  28-71:  failure  of  mission  flight,  AV  lost 

Indicates  the  number  of  1-min  checks  that  have  been  made;  if 
necessary  to  change  climbout  to  10  min,  changes  N1  and  N2  of 
mode  29  to  10. 

Arc  29-30:  climbout  OK,  all  systems  good  for  5  min 
Arc  29-25:  updates  1-min  counter  (node  25)  to  stop 

Indicates  loss  of  AV  control  through  GCS  passing  arcs  137  to  139, 

resulting  in  the  loss  of  an  AV 

Arc  37-45:  if  via  arc  137-139,  GCS  down 

Arc  37-58:  GCS  OK,  continue 

Indicates  GCS  failure  to  the  point  at  which  control  of  an  AV 
cannot  be  maintained,  28  occurs  where  flight  is  stopped,  AV  lost 
Arc  45-37:  resets  node  back  upon  starting  a  prelaunch 
Arc  45-29:  updates  5-min  counter  (-5) 

Arc  45-25:  updates  1-min  counter  (-2) 

Arc  45-71:  stops  flight  and  exits 

Indicates  whether  GCS  passed  arc  138-140  which  means  GCS  cannot 
perform  a  flight,  but  control  of  AV  is  still  good  enough  to 
attempt  a  recovery 

Arc  58-68:  done  by  arc  138-140  GCS  down/start  recovery 
Arc  58-29:  update  5-min  counter 

Arc  58-25:  ready  to  begin  next  1-min  check;  distribution  1, 
parameter  1 

Indicates  GCS  failure,  but  control  of  AV  is  still  possible,  then  [i 

occurs,  then  exit  baseline  model  and  recover 

Arc  68-58:  GCS  OK,  reset 

Arc  68-29:  update  5-min  counter 

Arc  68-25:  update  1-min  counter 

Arc  68-165:  start  recovery  part  of  flight 


Indicates  beginning  of  outbound  system  check,  starting  with  operation 
of  AV  subsystems 

Arc  30-31:  AV  subsystem  failed,  exit  via  0 
Arc  30-32:  AV  subsystems  OK,  continue 
Arc  30-36:  update  1-min  counter  to  ready 


OUTBOUND,  MISSION  (Figure  7) 


Indicates  AV  subsystem  failure;  from  103  to  108  and  109  if  MP  is 

included  in  dataset 

Arc  31-30:  flight  over,  reset 

Arc  31-39:  update  20-min  counter 

Arc  31-71:  stop  flight,  mission  flight  failure  due  to  AV  subsystem 
Arc  31-36:  update  1-min  counter  to  stop 

Indicates  ground-equipment  system  check 
Arc  32-33:  done  by  |5)  showing  failure 
Arc  32-75:  ground  equipment  OK,  continue 

Indicates  ground  equipment  failure 

Arc  33-32:  ground  equipment  fixed  via  0 

Arc  33-39:  update  20-min  counter  (-20) 

Arc  33-71:  mission  flight  failure,  AV  lost 
Arc  33-36:  update  1-min  counter  to  stop 

(see  37) 

Arc  75-76:  caused  by  arc  137-139,  GCS  down 
Arc  75-77:  GCS  OK,  continue 

(see  45) 

Arc  76-75: 

Arc  76-71: 

Arc  76-36: 

Arc  76-39: 

(see  58) 

Arc  77-78:  done  by  arc  138-140,  GCS  down/start  recovery 
Arc  77-34:  GCS  OK,  continue 

(see  68) 

Arc  78-77:  GCS  OK,  reset  arc  to  prelaunch 
Arc  78-39:  update  20-min  counter 
Arc  78-36:  update  1-min  counter 
Arc  78-154:  start  recovery  part  of  flight 


resets  GCS  back  to  working  status  upon  prelaunch  0 
stops  flight  and  exits 
updates  1-min  counter  to  stop 
updates  20-rain  counter  (-20) 


Node 


Significance 
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34  Indicates  environmental  check  for  the  possibility  of  being  shot  down 
Arc  34-38:  AV  survived  .999  on  arc 

Arc  34-35:  AV  shotdown  .001  on  arc 

35  Indicates  AV  shot  down-lost 

Arc  35-39:  update  20-min  counter  (-20) 

Arc  35-71:  mission  flight  failure,  AV  lost 
Arc  35-36:  update  1-min  counter  to  stop 

38  Indicates  AV  survived/split  node  from  probability  node 

Arc  38-36:  ready  to  begin  next  1-min  check;  distribution  1, 
parameter  1 

Arc  38-39:  update  20-min  counter  (1) 

36  Indicates  start  of  1-min  counter  which  sequences  the  checks 
Arc  36-30:  start  check  again 

39  Indicates  the  number  of  1-min  checks  that  have  been  made 

Arc  39-40:  outbound  flight  good,  continue  1  min  j_4J  distribution  1, 
parameter  1 

Arc  39-36:  stop  1-min  counter,  reset  (-1) 

Arc  39-36:  stop  1-min  counter  (-1,  1  min) 

40  Indicates  beginning  of  mission  system  check  and  check  of 
AV  subsystems 

Arc  40-41:  AV  subsystem  failed,  exit  via  {ToJ 
Arc  40-44:  update  1-min  counter  to  ready 
Arc  40-42:  AV  subsystems  OK,  continue 

41  Indicates  AV  subsystem  failure;  from  103  to  108  and  109  if  MP 
included  in  dataset 

Arc  41-40:  flight  over,  reset 

Arc  41-49:  update  120-min  counter  (two-60's) 

Arc  41-44:  update  1-min  counter  to  stop 
Arc  41-71:  mission  flight  failure 

42  Indicates  ground  equipment  system  check 
Arc  42-43:  done  by  £|]  failure 

Arc  42-79:  ground  equipment  OK,  continue 

43  Indicates  ground  equipment  failure 

Arc  43-42:  ground  equipment  fixed  via  0 
Arc  43-49:  update  120-min  counter  (two-60' s) 

Arc  43-44:  update  1-min  counter  to  stop 
Arc  43-71:  mission  flight  failure 

44  Indicates  start  of  1-min  counter  which  sequences  the  checks 
Arc  44-40:  start  check  again 
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Node 


Significance 


79  (see  37) 

Arc  79-145:  caused  by  arc  137-139,  GCS  down 
Arc  79-146:  GCS  OK,  continue 


145 


(see  45) 

Arc  145-79: 
Arc  145-49: 
Arc  145-71: 
Arc  145-44: 


resets  node  back  upon  starting  a  prelaunch 
updates  120-mln  counter  (two-60’s) 
stops  mission  and  exits 
updates  1-min  counter  (-2) 


146  (see  58) 

Arc  146-147:  caused  by  arc  138-140,  GCS  down/start  recovery 
Arc  146-46:  GCS  OK,  continue 


147 


(see  68) 

Arc  147-146: 
Arc  147-154: 
Arc  147-49: 
Arc  147-44: 


GCS  OK,  reset 

start  inbound  and  recovery  of  AV 
update  120-min  counter 
update  1-min  counter 


46  Indicates  environmental  check  for  the  possibility  of  being  shot  down 
Arc  46-47:  AV  shot  down  (.001  on  arc) 

Arc  46-48:  AV  survived  (.999  on  arc) 

47  Indicates  AV  shot  down  —  lost 

Arc  47-49:  update  20-min  counter  (-120) 

Arc  47-71:  mission  flight  failure,  AV  lost 
Arc  47-44:  update  1-min  counter  (-2)  to  stop 

48  Indicates  AV  survived /split  node  from  probability  node 
Arc  48-49:  update  120-min  counter  (1) 

Arc  48-44:  ready  to  begin  next  1  min 


49  Indicates  the  number  of  1-min  checks  made  during  the  mission 
Arc  49-50:  mission  good,  continue  with  inbound  1  min  fT) 
distribution  1,  parameter  1 
Arc  49-49:  stop  1-min  counter  reset  (-1) 

Arc  49-44:  stop  1-min  counter  reset  (-1,  1  min) 


50  Indicates  how  many  times  the  RPV  passed  the  mission  (statistics  node) 
Arc  50-53:  send  pulse  on 

51/52  Indicates  the  number  of  "sets  of  three"  of  completed  missions 
(both  nodes  do  the  same  job) 
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INBOUND,  RECOVERY  (Figure  8) 

Node  _ Significance _ 

53  Indicates  beginning  of  inbound  systems  check,  starting  with 
operation  of  AV  subsystems 

Arc  53-54:  AV  subsystem  failed,  exit  via  [Tol 
Arc  53-56:  AV  subsystem  OK,  continue 

Arc  53-57:  update  1-min  counter 

54  Indicates  subsystem  failure  from  103  to  108  and  109  if  MP  is 
included  in  dataset 

Arc  54-53:  flight  over,  reset 

Arc  54-62:  update  25-min  counter  (-25) 

Arc  54-57:  update  1-min  counter  to  stop 

Arc  54-71:  stop  flight,  mission  flight  failure  due  to  AV  subsystem 

56  Indicates  ground  equipment  system  check 

Arc  56-55:  done  by  [L5)  failure 
Arc  56-148:  ground  equipment  OK,  continue 

55  Indicates  equipment  failure 

Arc  55-56:  ground  equipment  fixed  via  R4| 

Arc  55-62:  update  25-min  counter  (-25) 

Arc  55-57:  update  1-min  counter  to  stop 

Arc  55-71:  mission  flight  failure,  AV  lost 

148  Indicates  loss  of  AV  control  through  GCS  passing  arcs  137-139, 
resulting  in  the  loss  of  an  AV 

Arc  148-149:  GCS  down  done  by  arc  137-139 
Arc  149-59:  GCS  OK,  continue 

149  Indicates  GCS  failure  to  the  point  at  which  control  of  an  AV  cannot 
be  maintained  ^8]  occurs  where  flight  is  stopped,  AV  lost 

Arc  149-148:  resets  node  back  upon  starting  a  prelaunch 
Arc  149-62:  updates  25-min  counter  (-25) 

Arc  149-57:  updates  1-min  counter  to  stop 
Arc  149-71:  stops  flight,  AV  lost,  and  exit 

59  Indicates  environmental  check  for  the  possibility  of  being  shot  down 

Arc  59-60:  AV  shot  down  (.001  on  arc) 

Arc  59-61:  AV  survived  (.999  on  arc) 

60  Indicates  AV  shot  down,  lost 

Arc  60-62:  update  25-min  counter 

Arc  60-71:  mission  flight  failure,  AV  lost 

Arc  60-57:  update  1-min  counter  to  stop 
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Node 


Significance 
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61  Indicates  AV  survived /split  node  from  probability  node 
Arc  61-62:  update  20-min  counter 

Arc  61-57:  ready  to  begin  next  1-min  check;  distribution  1, 

parameter  1 

57  Indicates  start  of  1-min  counter  which  sequences  the  checks 
Arc  57-53:  start  check  again 

62  Indicates  the  number  of  1-min  checks  that  will  be  made.  (If 
necessary,  inbound  can  be  changed,  for  example,  from  25  to  30, 
simply  by  replacing  N1  and  N2  with  30  in  node  62) 

Arc  62-63:  inbound  flight  good,  continue  1  min;  distribution  1, 

parameter  1 

Arc  62-57:  stop  1-min  counter  reset  (-1) 

Arc  62-57:  stop  1-min  counter  reset  (-1,  1  min) 

63  Indicates  beginning  of  recovery,  checking  of  AV  subsystems 

Arc  63-64:  AV  subsystem  failed,  exit  via  0 

Arc  63-66:  AV  subsystem  OK,  continue 

Arc  63-67:  update  1-min  counter  to  ready 

64  Indicates  AV  subsystem  failure  from  103  to  108  and  109  if  MP  included 
in  dataset 

Arc  64-63:  flight  over,  reset 

Arc  64-69:  update  10-min  recovery  counter 

Arc  64-67:  update  1-min  recovery  counter  to  stop 

Arc  64-71:  mission  flight  failure 

66  Indicates  ground  equipment  system  check 
Arc  66-65:  done  by  [L5j  failure 

Arc  66-150:  ground  equipment  OK,  continue 

65  Indicates  ground  equipment  failure 

Arc  65-66:  ground  equipment  fixed  via  0 

Arc  65-71:  mission  flight  failure 

Arc  65-69:  update  10-min  counter  (-10) 

Arc  65-67:  update  1-min  counter  to  stop 

151  Indicates  GCS  failure  to  the  point  at  which  control  of  AV  cannot  be 
maintained  [28]  occurs  where  flight  is  stopped,  AV  lost 
Arc  151-150:  resets  node  back  upon  starting  a  prelaunch  m 
Arc  151-67:  updates  1-min  counter  to  stop 
Arc  151-69:  updates  10-min  counter  (-10) 

Arc  151-71:  stops  flight,  AV  lost,  and  exit 

67  Indicates  start  of  1-min  counter  which  sequences  the  checks 

Arc  67-63:  starts  check  again 


I 
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Significance 


Indicates  the  number  of  1-min  checks  during  the  recovery  that  have 
been  made 

Arc  69-70:  recovery  good  (till  net),  continue  with  probability 

of  net  working 

Arc  69-69:  stop  1-min  counter  reset  (-1) 

Arc  69-67:  stop  1-min  counter  reset  (-1,  1  min) 

Indicates  the  probability  that  recovery  net  works 
Arc  70-72:  net  work  good,  AV  recovered  (.99) 

Arc  70-71:  net  failed,  AV  lost  (.01) 


RECOVERY,  TIMER  (Figure  9) 


Indicates  mission  flight  failure;  AV  lost;  however,  if  MP  failed, 
then  mission  is  not  considered  a  failure 

Indicates  whether  failure  occurred  in  MP 

Arc  289-288:  if  failure  in  MP,  hold 

Arc  289-152:  failure  not  in  MP;  AV  lost,  reset 

Indicates  pulse  stopped;  MP  failed  but  AV  in  recovery  mode;  pulse 
reestablished  from  subrecovery  mode 
Arc  288-289:  reset 

Indicates  mission  flight  successful;  no  problems  disrupted  the  baseline 

program;  mission  counts  as  one  good  3-hr  sortie 

Arc  72-73:  update  3-sortie  counter 

Arc  72-152:  update  GCS  available 

Arc  72-74:  put  AV  back  in  pool 

Indicates  the  number  of  days  in  which  three  3-hr  sorties  were 
completed  successfully 

Arc  73-102:  (32|  stop  12-hr  clock;  three  mission  flights  have  been 

completed  within  the  time  period 

Indicates  AV  replacement  into  pool 

Arc  74-5:  where  5  is  pool,  -1  to  add  to  counter 

Indicates  GCS  checked  for  readiness 

Arc  152-153:  stop  and  hold  until  GCS  is  fixed 

Arc  152-6:  GCS  available,  start  prelaunch  again 

Indicates  system  holding  until  GCS  is  ready 
Arc  153-152:  GCS  is  ready,  return 

Arc  152-152:  1-min  loop.  Checks  status  of  GCS  every  1  min 
(helps  prevent  infinite  loops) 


Mode 


Significance 


101  Indicates  start  of  12-hr  clock  at  beginning  of  simulation;  if  clock 
runs  out  before  completion  of  three  good  sorties  (Arc  73-102) , 
simulation  is  terminated  (end  of  daylight  hrs) 

Arc  101-102:  12  hr  have  passed 

102  Indicates  pulse  received  for  completion  of  three  mission  flights  or  for 
completion  of  12-hr  period 

Arc  102-180:  three  sorties  completed  first 
Arc  102-181:  12  hrs  have  passed 

180  Indicates  three  mission  flights  were  completed,  12-hr  clock  starts 
again  and  records  in  N229 

Arc  180-1G1:  starts  12-hr  clock  for  next  day,  model  starts  prelaunch 
automatically  with  Arc  152-6 
Arc  180-299:  decrease  299  by  one 

299  Indicates  maximum  of  10  successful  days,  then  stops  simulation  run 
Arc  299:  sink  node 

181  Indicates  three  sorties  were  not  completed  within  12  hrs;  12  hr 
arrived  at  102  first  and  diverted  to  181 

Arc  181-182:  send  pulse  to  stop  simulation 

182  Indicates  12  hrs  over  before  three  mission  flights,  collect  statistics 

Arc  182:  sink  node 


AV  SUBSYSTEM  (Figure  10) 


80  Indicates  beginning  of  simulation;  starts  all  components  of  AV 
Arc  80-103:  starts  FCEP  distribution 
Arc  80-104:  starts  ARA  distribution 
Arc  80-105:  starts  ADT  distribution 
Arc  80-106:  starts  electric  power  distribution 
Arc  80-107:  starts  airframe  distribution 
Arc  80-108:  starts  prop  distribution 
Arc  80-109:  starts  mission  payload  distribution 

103  Indicates  beginning  of  distribution  for  FCEP 

Arc  103-81:  distribution  4,  parameter  9,  number  10 

104  Indicates  beginning  of  distribution  for  ARA 

Arc  104-81:  distribution  4,  parameter  10,  number  10 

105  Indicates  beginning  of  distribution  for  ADT 

Arc  105-81:  distribution  4,  parameter  11,  number  10 
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Node 


Significance 


106  Indicates  beginning  of  distribution  for  electric  power 
Arc  106-81:  distribution  4,  parameter  12,  number  10 

107  Indicates  beginning  of  distribution  for  the  airframe 
Arc  107-81:  distribution  4,  parameter  13,  number  10 

108  Indicates  beginning  of  distribution  for  the  prop 

Arc  108-81:  distribution  4,  parameter  14,  number  10 

109  Indicates  beginning  of  distribution  for  the  MP 

Arc  109-183:  distribution  4,  parameter  4,  number  11 

183  Indicates  failure  of  mission  payload 

Arc  183-81:  failure  occurred  in  mission  payload  during  prelaunch 

check 

Arc  183-184:  node  exchange  done  after  prelaunch  [T] 

81  Indicates  failure  in  an  AV  subsystem  (from  103  to  108  and  183) 
or  distributions  stop  and  restart;  by  2  (the  H  denotes  the  halt 
command  specified  in  GRASP  in  which  one  pulse  is  received,  and 
the  others  are  ignored) 

Arc  81-82:  hold  pulse  until  prelaunch  is  ready  again 

Arc  81-80:  start  a  new  set  of  AV  distribution  for  an  AV  on 

the  launcher 

82  Indicates  pulse  is  postponed  until  prelaunch  is  ready 

Arc  82-82:  return  pulse 

Arc  82-81:  return  pulse  to  node  81  to  start  A 

184  Indicates  failure  of  mission  payload  after  prelaunch  before 
mission  return  of  AV 

Arc  184-183:  reset  node  back  before  prelaunch 
Arc  184-186:  failure  occurred,  start  recovery 

185  Indicates  failure  of  mission  payload  during  mission  return  of  AV 
via  an  inbound  flight 

Arc  185-186:  reset  back  with  |*5~j 

Arc  185-154:  send  pulse  to  auxiliary  recovery  —  inbound 

186  Indicates  failure  of  mission  payload  during  climbout  and  outbound  flight 
Arc  186-165:  send  pulse  to  auxiliary  recovery 

Arc  186-185:  divert  pulse  to  auxiliary  recovery  on  inbound  if 
mission  payload  fails 
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GROUND  EQUIPMENT  (Figure  10) 


Node  _ Significance _ 

85  Indicates  beginning  of  simulation 

Arc  85-86:  starts  RGT  failure  distribution;  distribution  4, 

parameter  3 

Arc  85-93:  updates  ground  equipment  status 

Arc  85-95:  update  ground  equipment  status 

86  Indicates  failure  of  RGT 

Arc  86-93:  update  ground  equipment  status 

Arc  86-95:  update  ground  equipment  status 

Arc  86-85:  repair  of  RGT;  distribution  1,  parameter  7 

87  Indicates  beginning  of  simulation 

Arc  87-88:  starts  generator  failure  distribution; 

distribution  4,  parameter  6 
Arc  87-89:  updates  ground  equipment  status 

Arc  87-92:  updates  ground  equipment  status 

88  Indicates  failure  of  generator  1 

Arc  88-87:  repair  of  generator  1;  distribution  1,  parameter  7 

Arc  88-89:  update  ground  equipment  status 

Arc  88-92:  update  ground  equipment  status 

89  Indicates  whether  one  of  two  generators  is  working 

Arc  89-93:  update  arc 

Arc  89-95:  update  arc 

Arc  89-92:  update  arc 

90  Indicates  beginning  of  simulation 

Arc  90-91:  starts  generator  failure  distribution 

Arc  90-89:  update  ground  equipment  status 

Arc  90-92:  update  ground  equipment  status 

91  Indicates  failure  of  generator  2 

Arc  91-90:  repair  of  generator  2;  distribution  1,  parameter  7 

Arc  91-92:  update  ground  equipment  status 

Arc  91-89:  update  ground  equipment  status 

92  Indicates  whether  or  not  both  generators  are  working 

Arc  92-95:  update  arc 

Arc  92-93:  update  arc 

Arc  92-89:  update  arc 

93  Indicates  GCS  status  (update  node) 

Arc  93-95:  update  arc 

Arc  93-94:  arc  for  ground  equipment  status  up  0 

94  Indicates  ground  equipment  working 
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Node 


Significance 


95  Indicates  GCS  status  (update  node) 

Arc  95-93:  update  arc 

Arc  95-96:  arc  for  ground  equipment  status  down  [15] 

96  Indicates  ground  equipment  not  working 


GROUND  CONTROL  STATION  (Figure  11) 


110  Indicates  beginning  of  GCS  subsystem  distributions 


Arc  110-111 
Arc  110-115 
Arc  110-119 
Arc  110-123 
Arc  110-127 
Arc  110-131 
Arc  110-5: 


starts  the  GCSIU  distribution 

starts  the  AVOC  console  distribution 

starts  the  MP  console  distribution 

starts  the  MC  console  distribution 

starts  the  NDU  distribution 

starts  the  main  computer  distribution 

subtracts  one  AV  from  the  AV-ready  pool  when  one 

AV  is  on  launcher  at  start  of  simulation  —  this 

is  easier  than  any  other  method 


111  Indicates  beginning  of  GCSIU  distribution 

Arc  111-112:  GCSIU  parameter  set  15,  distribution  4 
Arc  111-141:  updater  arc  for  GCS  up  (141-142) 

Arc  111-143:  updater  arc  for  GCS  down  (143-144) 


112  Indicates  GCSIU  failure 

Arc  112-111:  start  repair;  parameter  21,  distribution  1,  number 
updater  arc  for  GCS  repaired 
updater  arc  for  GCS  down 

timed  check  to  see  if  GCSIU  can  be  repaired  before 
fail  is  scheduled;  distribution  1,  parameter  set  27 


Arc  112-141: 
Arc  112-143: 
Arc  112-113: 


0 


113  Indicates  available  time  for  on-site  repair  has  passed  and  observed 
vehicle  must  be  scheduled  for  repair  —  GCSIU 

Arc  113-114:  repair  did  not  take  place  within  check  time  schedule 
failure 

Arc  113-114:  divert  pulse  to  stop  0 
Repair  has  taken  place  within  the  check  time 

114  Indicates  pulse  stopped,  failure  of  GCSIU 
Arc  114-113:  reset  back  B"6] 


115  Indicates  beginning  of  AVOC  distribution 

Arc  115-116:  AVOC  parameter  set  16,  distribution  4 
Arc  115-141:  updater  arc  for  GCS  up  (141-142) 

Arc  115-143:  updater  arc  for  GCS  down  (143-144) 

Arc  115-135:  updater  for  two  console  failure 
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116 


Indicates  AVOC  failure 

Arc  116-115:  start  repair  parameter  set  22,  distribution  1 
Arc  116-141:  updater  arc  for  GCS  repaired 
Arc  116-142:  updater  arc  for  GCS  down 

Arc  116-117:  timed  check  to  see  if  AVOC  can  be  repaired  before 
failing;  parameter  set  27,  distribution  1 

117  Indicates  available  time  for  on-site  repair  has  passed  and 
observed  vehicle  must  be  scheduled  for  repair  —  AVOC 

Arc  117-135:  repair  did  not  take  place  within  check  time; 
schedule  failure 

Arc  117-136:  repair  did  not  take  place  within  check  time; 
schedule  failure 

Arc  117-118:  divert  pulse  to  stop  [l9] 

118  Indicates  pulse  stopped  due  to  failure  of  AVOC 
Arc  118-117:  reset  back  |l8] 

119  Indicates  beginning  of  MPC  distribution 

Arc  119-120:  MPC  parameter  set  17,  distribution  4 
Arc  119-141:  updater  arc  for  GCS  up  (141-142) 

Arc  119-143:  updater  arc  for  GCS  down  (143-144) 

Arc  119-135:  updater  for  two  console  failure 

120  Indicates  MPC  failure 

Arc  120-119:  start  repair  parameter  set  23,  distribution  1 
Arc  120-141:  updater  arc  for  GCS  repaired 

Arc  120-142:  updater  arc  for  GCS  down 

Arc  120-121:  timed  check  to  see  if  MPC  can  be  repaired  before 
failing  parameter  set  27,  distribution  1 

121  Indicates  available  time  for  on-site  repair  has  passed  and  observed 
vehicle  must  be  scheduled  for  repair  —  MPC 

Arc  121-135:  repair  did  not  take  place  within  check  time  failure 
scheduled 

Arc  121-136:  repair  did  not  take  place  within  check  time  failure 
scheduled 

Arc  121-122:  divert  pulse  to  stop  [2l] 

122  Indicates  pulse  stopped  for  failure  of  MPC 
Arc  122-121:  repet  back  [2^ 

123  Indicates  beginning  of  MCC  distribution 

Arc  123-124:  MPC  parameter  set  18,  distribution  4 
Arc  123-141:  updater  arc  for  GCS  up  (141-142) 

Arc  123-143:  updater  arc  for  GCS  down  (143-144) 

Arc  123-135:  updater  for  two  console  failures 
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124 


Indicates  MCC  failure 

Arc  124-123:  start  repair  parameter  set  24,  distribution  1 
Arc  124-141:  updater  arc  for  GCS  repaired 
Arc  124-143:  updater  arc  for  GCS  down 

Arc  124-125:  timed  check  to  see  if  MCC  can  be  repaired  before  falling 
parameter  set  27 ,  distribution  1 

125  Indicates  time  over  —  MCC 

Arc  125-135:  repair  did  not  take  place  within  check  time 
failure  schedule 

Arc  125-136:  repair  did  not  take  place  within  check  time 
failure  schedule 

Arc  125-126:  divert  pulse  to  stop 

126  Indicates  pulse  stopped  for  failure  of  MCC 
Arc  126-125:  reset  back  [22] 

127  Indicates  beginning  of  NDU  distribution 

Arc  127-129:  NDU  parameter  set  19,  distribution  4 
Arc  127-141:  updater  arc  for  GCS  up  (141-142) 

Arc  127-143:  updater  arc  for  GCS  down  (143-144) 

128  Indicates  NDU  failure 

Arc  128-127:  start  repair  parameter  set  25,  distribution  1 
Arc  128-141:  updater  arc  for  GCS  repaired 

Arc  128-143:  updater  arc  for  GCS  down 

Arc  128-129:  timed  check  to  see  if  NDU  can  be  repaired  before 
failing;  parameter  set  27,  distribution  1 

129  Indicates  time  over  —  NDU 

Arc  129-138:  repair  did  not  take  place  within  check  time 
recovery  scheduled 
Arc  129-130:  divert  pulse  to  stop 

130  Indicates  pulse  stopped  for  NDU  failure 
Arc  130-129:  reset  back  [24] 

131  Indicates  beginning  of  main  computer  distribution 

Arc  131-132:  main  computer  parameter  set  20,  distribution  4 
Arc  131-141:  updater  arc  for  GCS  up  (141-142) 

Arc  131-143:  updater  arc  for  GCS  down  (143-144) 

132  Indicates  main  computer  failure 

Arc  132-131:  start  repair;  parameter  set  26,  distribution  1 
Arc  132-141:  updater  arc  for  GCS  repaired 

Arc  132-143:  updater  arc  for  GCS  down 

Arc  132-133:  timed  check  to  see  if  main  computer  can  be  repaired 
before  failing;  distribution  1,  parameter  set  27 
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Node 


Significance 


133  Indicates  time  over  —  main  computer 

Arc  133-138:  repair  did  not  take  place  within  check  time 
,  recovery  scheduled 

Arc  133-134:  divert  pulse  to  stop  ^7] 

134  Indicates  pulse  stopped  due  to  failure  of  main  computer 
Arc  134-133:  reset  back  |f6] 

135*  Indicates  failure  of  two  consoles 

Arc  135-137:  failure  of  GCS  —  if  AV  is  in  the  air,  it's  lost 

136*  Indicates  failure  of  one  console 

Arc  136-138:  start  recovery  operations 

137  Indicates  GCS  failure,  loss  of  AV 

Arc  137-139:  failure  of  GCS  scheduled  a  ^  for  the  main  model 

Arc  137-176:  guard  —  protect  from  having  two  pulses  issued  along 

arc  137-139  for  a  mission  flight 

139  Indicates  loss  of  AV 

176  Indicates  pulse  stopped;  only  one  pulse  needed 
Arc  176-137:  reset  by  [l] 

138  Indicates  failure  of  GCS,  AV  returned  for  recovery 

Arc  138-140:  failure  of  GCS  schedule  a  ^  for  the  main  model 

140  Indicates  beginning  of  recovery 

177  Indicates  pulse  stopped  —  only  one  pulse  needed 

141  Indicates  GCS  repaired 

Arc  141-142:  schedule  ^  f°r  main  model 
Arc  141-143:  (5)  GCS  repaired,  update 

142  Indicates  GCS  repaired 

143  Indicates  GCS  not  working 

Arc  143-144:  GCS  down,  schedule  ^  for  main  model 
Arc  143-141:  GCS  down,  update 

144  Indicates  GCS  not  working 


*The  three-console  model  here  should  be  redesigned  so  that  three  dis¬ 
tributions  (or  as  many  as  necessary)  could  be  altered  to  indicate  loss  of 
AV  control  to  the  extent  that  (1)  the  mission  would  be  aborted  and  the  AV 
recovered  or  (2)  recovery  would  be  impossible  and  the  AV  lost. 
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AUXILIARY  RECOVERY  (Figure  12) 


Significance 


Indicates  beginning  of  auxiliary  inbound  system  check,  starting  with 
all  AV  subsystems 


Arc  154-155 
Arc  154-156 
Arc  154-163 


AV  subsystem  failed,  exit  via 
AV  subsystem  continue 
update  1-min  counter 


Indicates  AV  subsystem  failure  from  103  to  108  and  109  if  MP  is 
included  in  dataset 


Arc  155-154 
Arc  155-164 
Arc  155-175 
Arc  155-163 


flight  over,  reset 
updater  for  25-min  counter 
mission  flight  failure,  AV  lost 
updater  for  1-min  counter 


Indicates  ground  equipment  system  check 

Arc  156-157:  done  £s|  failure 

Arc  156-158:  ground  equipment  OK,  continue 

Indicates  ground  equipment  failure 
Arc  157-156:  ground  equipment  fixed  via  0 
Arc  157-164:  updater  for  25-min  counter 
Arc  157-175:  mission  flight  failure,  AV  lost 
Arc  157-163:  updater  for  1-min  counter 

Indicates  loss  of  AV  control  through  arc  137-139,  resulting  in 
loss  of  AV 

Arc  158-159:  AV  lost 

Arc  137-139:  GCS  inoperative 

Arc  158-160:  GCS  operating,  continue  mission 

Indicates  GCS  failure  to  the  point  at  which  control  of  an  AV  cannot 
be  maintained  ^8]  occurs  where  flight  is  stopped  and  AV  lost 
Arc  159-158:  reset  node  back  upon  starting  a  prelaunch 
Arc  159-175:  stops  flight,  AV  lost,  and  exit 
Arc  159-164:  updates  25-min  counter 
Arc  159-163:  updates  1-min  counter 


Indicates  environmental  check  for  the  possibility  of  being  shot  down 
Arc  160-162:  AV  survived  (.999  on  arc) 

Arc  160-161:  AV  shot  down  (.001  on  arc) 

Indicates  AV  survived /split  node  from  probability  node 
Arc  162-164:  update  20-min  counter 

Arc  162-163:  ready  to  begin  next  1-min  check;  distribution  1, 
parameter  set  1 


Node 


Significance 


161  Indicates  AV  shot  down  —  lost 

Arc  161-164:  update  25-min  counter 

Arc  161-163:  update  1-min  counter 

Arc  161-175:  mission  flight  failure,  AV  lost 

163  Indicates  start  of  1-min  counter  which  sequences  the  checks 
Arc  163-154:  start  check  again 

164  Indicates  the  number  of  1-min  checks  that  have  been  made. 
Arc  164-163:  stop  1-min  counter,  reset  (-1) 

Arc  164-163:  stop  1-min  counter,  reset  (-1,  1  min) 

Arc  164-165:  inbound  flight  good,  continue 

165  Indicates  beginning  of  recovery,  checking  of  AV  subsystem 
Arc  165-166:  AV  subsystem  failed,  exit  via  0 

Arc  165-161:  update  1-min  counter  to  ready 
Arc  165-167:  AV  subsystem  OK,  continue 


166  Indicates  AV  subsystem  failure  from  103  to  108  and  109  if  MP 
included  in  dataset 

Arc  166-165:  flight  over,  reset 

Arc  166-172:  update  10-min  recovery  counter 

Arc  166-171:  update  1-min  recovery  counter  to  stop 

Arc  166-175:  mission  flight  failure 

167  Indicates  GCS  failure  to  the  point  at  which  control  of  an  AV  cannot 

be  maintained  occurs 

Arc  167-168:  resets  node  back  upon  starting  a  prelaunch  [T] 

Arc  167-169:  GCS  OK,  continue 


168  Indicates  GCS  failure,  AV  lost 

Arc  168-172:  update  10-min  recovery  counter 

Arc  168-171:  update  1-min  counter 

Arc  168-175:  mission  flight  failure,  AV  lost 


169  Indicates  ground  equipment  system  check 
Arc  169-170:  done  by  |l5]  failure 

Arc  169-172:  ground  equipment  working,  continue 

170  Indicates  ground  equipment  failure 

Arc  170-169:  ground  equipment  fixed  via  0 

Arc  170-172:  update  10-min  counter 

Arc  170-171:  update  1-min  counter  to  stop 

171  Indicates  start  of  1-min  counter  which  sequences  the  system  checks 
Arc  171-165:  starts  check  again 
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Node 


Significance 


172  Indicates  the  number  of  1-min  checks  made  during  the  recovery 
Arc  172-173:  recovery  good  (until  net),  continue  with 

probability  of  net 

Arc  172-171:  stop  1-min  counter,  rest  (-1) 

Arc  172-171:  stop  1-min  counter,  reset  (-1,  1  min) 

173  Indicates  probability  that  recovery  net  works 

Arc  173-174:  .95  recovery  good 

Arc  173-175:  .05  recovery  bad 

Arc  173-187:  node  exchange  (if  MP  is  bad,  probability  is  lower  0) 

187  Indicates  probability  that  recovery  net  works  without  MP  for  guidance 
Arc  187-190:  recovery  good  .93 
Arc  187-175:  recovery  bad 

290  Indicates  recovery  good,  MP  failed 

Arc  290:  MS  send  AV  to  MS  to  be  repaired 

Arc  290-152:  start  new  mission  flight 

174  Indicates  recovery  good 

Arc  174-5:  AV  OK,  return  to  ready  pool 

Arc  174-152:  start  new  mission  flight 

175  Indicates  recovery  unsuccessful,  AV  lost 

Arc  175-152:  start  new  mission  flight 


MSI  100%  DIAGNOSTICS  (Figure  13) 


200  Indicates  initialization  of  maintenance  shelter  1 

Arc  200-201:  distribution  1,  parameter  set  27,  installation  time 

201  Indicates  test  of  test  equipment 
Arc  201-103:  test  good  .99 

Arc  201-202:  test  not  good  .01,  keys  in  AVIM 

202  AVIM 

203  Indicates  time  for  fault  isolation  to  work 

Arc  203-204:  parameter  set  27,  distribution  1,  fault  isolation 

204  Indicates  probability  of  fault  being  detected 

Arc  204-206:  fault  not  detected  .05 

Arc  204-205:  fault  detected  .95 

205  Indicates  probability  of  repairing  the  fault  with  an  LRU 
Arc  205-202:  cannot  be  repaired  at  AVUM  (.10) 

Arc  205-207:  repaired  at  AVUM  .90 
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Node 


Significance 


206  Indicates  that  repair  may  need  to  take  place  in  GSE,  LA,  REC,  GCS, 
or  RGT 

Arc  206-210:  transfer  of  pulse 

207  Indicates  time  to  replace  LRU 

Arc  207-209:  distribution  1,  parameter  set  27 

209  Indicates  service  check 

Arc  209-210:  service  good  .999 

Arc  209-201:  service  not  good,  start  again  .001 

210  Indicates  service  good,  send  AV  back  to  AV  ready  pool 

Arc  210-5:  AV  to  ready  pool 


MS2  70%  CHARACTERISTICS  (Figure  13) 


220  Indicates  initialization  of  maintenance  shelter  2 
Arc  220-221:  distribution  1,  parameter  set  27 

221  Indicates  idle  mode 

Arc  221-222:  transfer  pulse 

222  Indicates  fault  isolation  time 

Arc  222-223:  distribution  1,  parameter  set  27 

223  Indicates  test  confirmed  from  GCS 

Arc  223-224:  test  not  confirmed  .05 
Arc  223-226:  test  confirmed  .95 

224  Indicates  check  of  testing  arrangement 

Arc  224-225:  test  arrangement  good  .95 

Arc  224-221:  test  arrangement  bad,  start  again 

225  Send  to  AVIM 

226  Indicates  isolation  to  LRU 

Arc  226-227:  confirmed  .90 
Arc  226-225:  not  possible  .10 

227  Indicates  AV  sent  to  repair 

Arc  227-228:  repair  time,  distribution  1,  parameter  set  27 

228  Indicates  end  of  repair 

Arc  228-229:  send  pulse  for  service  check 
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229  Indicates  service  check 

Arc  229-225:  no  good,  send  to  AVIM  .10 
Arc  229-230:  service  good  .90 

230  Indicates  service  good,  send  AV  back  to  ready  pool 

Arc  230-5:  AV  to  ready  pool 


MS3  CONTRACT  SPECIFICATIONS  (Figure  13) 


3-188  Indicates  installation  time;  distribution  1,  parameter  set  1 

188  Indicates  test  for  faults 

Arc  188-189:  distribution  1,  parameter  set  7 

189  Indicates  probability  of  problem  being  fixed 
Arc  189-190:  .10,  sent  to  AVIM 

Arc  180-191:  .90,  send  to  repair 

190  AVIM 

191  Indicates  repair  time  —  send  back  to  ready  pool 

Arc  191-5:  parameter  8  Q  ,  distribution  1 


APPENDIX  C 


PARAMETER  SET 


This  section  describes  the  numbers  used  for  the  distributions.  The 
distributions  u3e  a  mean  time  for  failure  rate  determination.  Minimum  and 
maximum  time-rates  are  associated  with  distributions  to  provide  a  means  for 
containment  of  times. 


Distribution  _ Significance _ 

1  Constant  1-min  timer;  used  mostly  for  1-min  system  checks  in 
main  program 

2  Constant  720-min  (12-hr)  timer;  used  to  time  1  day's  activities 

Arc  101-102 

3  Exponential  distribution  on  RGT 

10000.0  mean  time  in  minutes 
0.0  minimum  time  in  minutes 
99999999.0  maximum  time  in  minutes 

1.0  puts  ERLANG-K  into  exponential 

4  Mission  payload 

10,312  mean  time  in  minutes 

0.0  minimum  time  in  minutes 
99999999.0  maximum  time  in  minutes 

1.0  puts  ERLANG-K  into  exponential 

5  Old  distribution  —  not  used 

6  Generators 

720,000  mean  time  in  minutes 

0.0  minimum  time  in  minutes 
99999999.0  maximum  time  in  minutes 

1.0  puts  ERLANG-K  into  exponential 

7  Constant  30-min  timer 

8  Constant  15-min  timer 

9  FCEP 

117,187.3  mean  time  in  minutes 

0.0  minimum  time  in  minutes 
190.0  maximum  time  in  minutes 

1.0  puts  ERLANG-K  into  exponential 
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Distribution 

10 


11 


12 


13 


14 


15 


16 


17 


Significance 


ARA 

229885  mean  time  in  minutes 
0.0  minimum  time  in  minutes 
190.0  maximum  time  in  minutes 

1.0  puts  ERLANG-K  into  exponential 

ADT 

287081.34  mean  time  in  minutes 
0.0  minimum  time  in  minutes 
190.0  maximum  time  in  minutes 

1.0  puts  ERLANG-K  into  exponential 

Electrical  power 

180180.18  mean  time  in  minutes 
0.0  minimum  time  in  minutes 
190.0  maximum  time  in  minutes 

1.0  puts  ERLANG-K  into  exponential 


Air  frame 

312500.00  mean  time  in  minutes 
0.0  minimum  time  in  minutes 
190.0  maximum  time  in  minutes 

1.0  puts  ERLANG-K  into  exponential 

Propulsion  assembly 

48000.0  mean  time  in  minutes 
0.0  minimum  time  in  minutes 
190.0  maximum  time  in  minutes 

1.0  puts  ERLANG-K  into  exponential 

GCS  IU 

48000.0  mean  time  in  minutes 
0.0  minimum  time  in  minutes 
99999999.0  maximum  time  in  minutes 

1.0  puts  ERLANG-K  into  exponential 

AVO  console 

22779.043  mean  time  in  minutes 
0.0  minimum  time  in  minutes 
99999999.0  maximum  time  in  minutes 

1.0  puts  ERLANG-K  into  exponential 


MP0  console 

63492.0635  mean  time  in  minutes 
0.0  minimum  time  in  minutes 
99999999.0  maximum  time  in  minutes 

1.0  puts  ERLANG-K  into  exponential 
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Distribution 

Significance 

18 

MC  console 

57416.2679  mean  time  in  minutes 

0.0  minimum  time  in  minutes 

99999999.0  maximum  time  in  minutes 

1.0  puts  ERLANG-K  into  exponential 

19 

NDU  console 

209790.210  mean  time  in  minutes 

0.0  minimum  time  in  minutes 

99999999.0  maximum  time  in  minutes 

1.0  puts  ERLANG-K  into  exponential 

20 

GCS  main  computer 

157480.0  mean  time  in  minutes 

0.0  minimum  time  in  minutes 

99999999.0  maximum  time  in  minutes 

1.0  puts  ERLANG-K  into  exponential 

21 

GCS  IU 

15.00  constant  repair  time 

22 

AVO  console 

15.00  constant  repair  time 

23 

MPO  console 

15.00  constant  repair  time 

24 

MC  console 

15.00  constant  repair  time 

25 

NDU  console 

15.00  constant  repair  time 

26 

GCS  main  computer 

15.00  constant  repair  time 

27 

Check  time  for  GCS  components 

10.00  constant  repair  time 
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Figure  14.-  GCS  reliability  block  diagram. 
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Figure  15.-  RPV  air  vehicle  subsystem  reliability  block  diagram. 


APPENDIX  D 


ACTIVITY  NUMBERS 


Activity  numbers  are  assigned  to  denote  different  stages  in  the  simula¬ 
tion.  This  section  describes  these  stages  and  which  arcs  are  used. 


0 

0 

s 

0 

m 


0 


eh 

0 

0 

0 

0 


Prelaunch  check  is  about  to  begin 
Arc  2-11 

Prelaunch  good/engine  start  and  launch  next 
Arc  17-18 

AV  has  passed  outbound  ready  to  begin  mission 
Arc  39-40 

AV  has  passed  mission,  mission  successful 

AV  has  completed  recovery  approach,  flight  over 

AV  subsystem  component  failure 

Mission  payload  failure 

Ground  equipment  working 

Ground  equipment  not  working 

Failure  of  GCS  IU 

Reapir  of  GCS  IU 

Failure  of  AVO  console 

Repair  of  AVO  console 

Failure  of  MPO  console 

Repair  of  MPO  console 

Failure  of  MC  console 

Repair  of  MC  console 

Failure  of  NAV  DPL  unit 


} 


i 

I 

s 

I  ' 
{■ 

j- 
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t- 


mi 

mi 


Repair  of  NAV  DPL  unit 

Failure  of  CCS  main  computer 

Repair  of  GCS  main  computer 

GCS  not  working 

GCS  repaired 

GCS  failure  —  A V  lost 

GCS  failure  —  AV  in  recovery /inbound 

(depends  on  AV  location) 

Successful  day  completed 

3-3  hr  sorties  within  12  hours 

Unsuccessful  day 

12-hr  timer  finished 


ACTIVITY  NUMBERS 
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APPENDIX  E 


DATA  SET  DESCRIPTIONS 


The  following  table  shows  which  data  set  contains  the  subelements  that 
supplement  the  GRASP/Army  RPV  Simulation  MAIN  Program. 


APPENDIX  F 


DETERMINATION  OF  DISTRIBUTIONS 


In  this  model,  Lockheed  uses  the  exponential  distribution  in  all  calcula¬ 
tions.  In  the  GRASP  Program  this  is  used  as  an  ERLANG-1  (K  ■  1),  because 
theoretically  the  exponential  distribution  is  a  particular  case  of  the 
ERLANG  distribution  when  K  =  1.  Thus  for  the  exponential  distribution  it  is: 

Mean  (MTBF)  -  j 

The  X’s  supplied  by  Lockheed  represent  the  failure  rates  per  million  (10**) 
hours.  Therefore,  the  mean  if  computed  is  1/original  X  is  expressed  in 
millions  of  hours;  and  1/X  x  10^  is  the  mean  expressed  in  hours;  and 
1/X  x  10^  x  60  is  the  mean  expressed  in  minutes.  This  last  case  is  used  to 
determine  the  failure  rates  since  the  RPV  system  model  operates  in  minutes. 


GCS  Subsystems 


AVO  Console 


X  -  2634 


Mean  *  x  106  x  60 

which  is  Parameter  Set  No.  16 


22779.04  min 


MPO  Console 


X  -  945 


Mean  ■ 

which  is  Parameter  Set  No. 


1 

945 


x  10 


17 


x  60 


63492.06  min 


MC  Console 


X  -  1045 


Mean  ■  .-j;v  x  10^  x  60 
1045 

which  is  Parameter  Set  No.  18 


57416.27  min 
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Navigation  PPL.  Console 
X  -  286 

Mean  -  x  io6  x  60  =  209790.2  min 
which  is  Parameter  Set  No.  19 

Computer  Signal-Processing  Unit 
X  -  381 

Mean  «  ^  x  io6  x  60  *  157A80  min 
which  is  Parameter  Set  No.  20 


Mission  Payload 


AV  Subsystem 


X  -  5818 

Mean  =  x  106  x  60  -  10312.82  min 

which  is  Parameter  Set  No.  4 


FCEP  and  FLT  Sensor  Packages 
X  -  512 

Mean  *  ^  x  106  x  60  -  117187.5  min 
which  is  Parameter  Set  No.  9 

ARA 

X  -  261 

Mean  *  ■—  x  IQ6  x  60  -  229885.06  min 


which  is  Parameter  Set  No.  10 


APT 

X  -  809 

Mean  “  8^9  x  1q6  x  60  "  74165.64  min 
which  is  Parameter  Set  No.  11 

Baseline  Electrical  Power 
X  -  333 

Mean  *  3J3  x  2°6  x  60  "  180180.18  min 
which  is  Parameter  Set  No.  12 

Air  Frame 

X  -  192 

Mean  *  192  X  1()6  x  60  *  312500  min 
which  is  Parameter  Set  No.  13 
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APPENDIX  G 


MAINTENANCE  SHELTER  CONCEPTS  (Diagram  8) 


In  Che  GRASP  Simulation  Program  three  different  types  of  maintenance 
systems  were  used  to  try  to  describe  different  types  of  diagnostic  testing 
techniques. 

Concept  1:  Options  for  entire  system  checkout.  Possibility  of  AV  being 
sent  to  MS  in  need  of  repair. 

Concept  2:  Model  from  a  LMSC  document  (LMSC-D732866) .  Purpose:  to  see 
if  GRASP  is  a  useful  tool  in  making  direct  modeling  adaptations. 

Concept  3:  A  model  resembling  a  similar  contract  requirement  in  which 
90%  of  the  AV's  are  repaired  and  returned  to  service 
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